dC10 Bec'd FOlVrTO 0 A M 2002 



390(Modified) U.S. DEPARTMENTOF COMMERCEPATENTAND TRADEMARKDFFIC E 

(REV 11 -98) 

TRANSMITTAL LETTER TO THE UNITED STATES 
DESIGNATED/ELECTED OFFICE (DO/EO/US) 
CONCERNING A FILING UNDER 35 U.S.C. 371 



ATTORNEY'SDOCKETNUMBER 
11345/042001 



U.S APPLICATIONS. (IF KNOWN.SEE 37 CFR 
fYDATECLAIMED 



INTERNATIONAIAPPLICATIONNO 
PCT/IB00/00968 



INTERNATIONALFILING DATE 
3 JULY 2000 



TITLE OF INVENTION 

COMMUNICATION METHODS AND APPARATUS 



,PPLICANT(S^ORDO/EO/US 
Gilles LEBOUILL 



Applicant herewith submits to the United States Designated/Elected Office (DO/EO/US) the following items and other information: 



This 
This 
This 



a FIRST submission of items concerning a filing under 35 U.S.C. 371. 
a SECOND or SUBSEQUENT submission of items concerning a filing under 35 U.S C 371 
an express request to begin national examination procedures (35 U.S C. 371(f)) at any time rather than delay 
ation until the expiration of the applicable time limit set m 35 U.S.C. 371(b) and PCT Articles 22 and 39(1). 
A proper Demand for International Preliminary Examination was made by the 19th month from the earliest claimed priority d 
A copy of the International Application as filed (35 U S.C. 371 (c) (2)) 

a. □ is transmitted herewith (required only if not transmitted by the International Bureau) 

b. EI has been transmitted by the International Bureau. 

c. □ is not required, as the application was filed in the United States Receiving Office (RO/US). 
A translation of the International Application into English (35 U.S.C 371(c)(2)) 
A copy of the International Search Report (PCT/ISA/210). 

,Qs. 33 Amendments to the claims of the International Application under PCT Article 19 (35 U.S.C. 371 (c)(3)) 

a. □ are transmitted herewith (required only if not transmitted by the International Bureau). 

b. □ have been transmitted by the International Bureau. 

c. □ have not been made; however, the time limit for making such amendments has NOT expired 

d. S have not been made and will not be made 

□ A translation of the amendments to the claims under PCT Article 19 (35 U.S.C 371(c)(3)). 
H An oath or declaration of the mventor(s) (35 U S.C 371 (c)(4)). 

El A copy of the International Preliminary Examination Report (PCT/IPEA/409). 

□ A translation of the annexes to the International Preliminary Examination Report under PCT Article 36 
(35 U.S C. 371 (c)(5)). 

terns 13 to 20 below concern document(s) or information included: 

H An Information Disclosure Statement under 37 CFR 1.97 and 1.98. 

K An assignment document for recording. A separate cover sheet in compliance with 37 CFR 3.28 and 3.31 is included. 

E3 A FIRST preliminary amendment. 

□. A SECOND or SUBSEQUENT preliminary amendment 

•gj A substitute specification. 

□ A change of power of attorney and/or address letter. 
H Certificate of Mailing by Express Mail 

□ Other items or information: 



Page 1 of 2 



PCTUS1/REV03 



JC13 Re«'d PCT/PTO 0 4 JAN 2002 



:AX10K\0 /IFKNOWN.SEI 

WtT.97 



[NTERNATIONAIAPPLICATIONNO. 
PCT/LB0O/O0968 



ATTORNEY'SDOCKETNUMBER 
11345/042001 



21. Thefol 


owing fees are submitted.. 




CALCULATIONS PTOUSEONLY 


BASIC NATIONAL FEE ( 37 CFR 1.492 (a) (1) - (5)) : 

□ Neither international preliminary examination fee (37 CFR 1 482) nor 
international search fee (37 CFR 1.445(a)(2) paid to USPTO 

and International Search Report not prepared by the EPO or JPO . . . . . $970.00 

B International preliminary examination fee (37 CFR 1.482) not paid to 

USPTO but Internation Search Report prepared by the EPO or JPO . . . $840.00 

□ International preliminary examination fee (37 CFR 1 482) not paid to USPTO 

but international search fee (37 CFR 1.445(a)(2)) paid to USPTO $690.00 

□ International preliminary examination fee paid to USPTO (37 CFR 1.482) 

but all claims did not satisfy provisions of PCT Article 33(l)-(4) $670.00 

□ International preliminary examination fee paid to USPTO (37 CFR 1.482) 

and all claims satisfied provisions of PCT Article 33(l)-(4) S96.00 

ENTER APPROPRIATE BASIC FEE AMOUNT = 




$890.00 




Surcharge of $130.00 for furnishing the oath or declaration later than □ 20 □ 30 
months from the earliest claimed priority date (37 CFR 1.492 (e)). 


$0.00 




CLAIMS 


NUMBER FILED 


NUMBER EXTRA 


RATE 




Total claims 


27 - 20 = 


7 


x $18.00 


$126.00 




Independent claims 


4 - 3 = 




x $84.00 


S84.00 




Multiple Dependent Claims (check if applicable) . 


□ 


$0.00 




! TOTAL OF ABOVE CALCULATIONS = 


$1,100.00 




Reduction of 1/2 for filing by small entity, if applicable. Verified Small Entity Statement 
must also be filed (Note 37 CFR 1.9, 1.27, 1.28) (check if applicable) . 


□ 


$0.00 




SUBTOTAL = 


$1,100.00 




pSbessing fee of $130.00 for furnishing the English translation later than □ 20 □ 30 
iMiths from the earliest claimed priority date (37 CFR 1.492 (f)). + 


$0.00 




TOTAL NATIONAL FEE 


$1,100.00 






Fsiafor recording the enclosed assignment (37 CFR 1 21(h)). The assignment must be 
agg>rnpanied by an appropriate cover sheet (37 CFR 3.28, 3 31) (check if applicable). 


ES 


$40.00 




TOTAL FEES ENCLOSED 


$1,140.00 




a 


Amount to be: 
refunded 


$ 


charged 


$ 



Q|] A check in the amount of $1,140.00 

Please charge my Deposit Account No. 
'i ll A duplicate copy of this sheet is enclosed. 



:r the above fees is enclosed 
m the amount of 



The Commissioner is hereby authorized to charge any fees which may be required, or credit any overpayment 
to Deposit Account No. 50-0591 A duplicate copy of this sheet is enclosed. 

petition to revive (37 CFR 



NOTE: Where an appropriate time limit under 37 CFR 1.494 
137(a) or (b)) must be filed and granted to restore the applies 



SEND ALL CORRESPONDENCE TO: 



ROSENTHAL & OSHA L.L.P. 
1221 McKinney, Suite 2800 
Houston, Texas 77010 

Telephone: (713) 228-8600 
Facsimile: (713) 228-8778 



A- 



Jonathan P. Osha 

NAME 
33,986 

REGISTRATION NUMBER 
January 4, 2002 



Page 2 of 2 



10/ Ui if oo 

JC13Ree s dPCT/PTG 0 4 JAN 2002 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Applicant: Gilles LEBOUILL Art Unit : 

Serial No.: Examiner : 

Filed : January 4, 2002 

Title : COMMUNICATION METHODS AND APPARATUS 

Assistant Commissioner for Patents 
Washington, DC 20231 

PRELIMINARY AMENDMENT 

Dear Sir: 

Before examining the referenced application on the merits, please amend the 

M 

p application as follows: 

a 

^ IN THE CLAIMS 

s 

H Please amend the claims as follows [a marked-up copy of the amended claims is 

q attached as Appendix A] : 

Q 3. (Amended) A method according to Claim 1 wherein the identifier is independent of a 

Pj 

network login identifier for the receiver/decoder. 

4. (Amended) A method according to claim 1, wherein the identifier is based on a 
number unique to a smartcard for use with the receiver/decoder. 

5. (Amended) A method according to claim 1, wherein the remote server is for 
accessing the internet. 

6. (Amended) A method according to claim I, wherein the remote server is an internet 
account management system. 

1 
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9. (Amended) A method according to Claim 7, wherein the remote server comprises 
means for sending data to an internet service provider and wherein said method comprises the 
steps of providing details of the internet account to the internet service provider to establish a bi- 
directional data pathway between the receiver/decoder and the internet service provider. 

10. (Amended) A method according to claim 1, wherein said identifier is accompanied by 
data identifying a data pathway to be used for communication between the receiver/decoder and 
the remote server. 

11. (Amended) A method according to claim 1, wherein the remote server provides the 
receiver/decoder with access to a network having network protocols, and data output from the 
receiver/decoder is converted into data compliant with the network protocols at a location remote 
from the receiver/decoder. 

14. (Amended) A method of communicating data from a non- internet protocol enabled 

user terminal to one of a plurality of internet protocol enabled remote devices, the method 
comprising the steps of: 

communicating data using said non-internet protocol from said user terminal to a 
gateway, said data including a message and specifying a destination for said message from said 
plurality of remote devices; and 

converting at said gateway said data into data using said internet protocol; and 

communicating said data using said internet protocol from said gateway to the 
specified destination remote device, thereby establishing a communication channel between the 
user terminal and the specified remote device. 
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16. (Amended) A method according to Claim 15, wherein a message instructing 
termination of the communication channel is communicated from the receiver/decoder to the 
gateway using the non-internet protocol, the gateway in turn communicating a termination 
command to the specified remote device using the internet protocol. 

17. (Amended) A method according to claim 15, wherein the identification of the 
receiver/decoder is authenticated by the gateway before the communication channel is 
established. 

20. (Amended) Apparatus according to Claim 18, wherein the remote server provides the 
receiver/decoder with access to a network having network protocols, said apparatus comprising 
means for converting data output from the receiver/decoder into data compliant with the network 
protocols. 

21. (Amended) Apparatus according to claim 18, comprising a gateway intermediate the 
receiver/decoder and the remote server. 

25 . (Amended) A gateway according to Claim 23 , comprising: 

means for identifying a message from the user terminal instructing termination of the 
communication channel; and 

means for passing a termination command to the specified remote device. 

Please add the following claims to the application: 

-29. (New) A method according to claim 13, wherein a message instructing termination of 
the communication channel is communicated from the receiver/decoder to the gateway using the 



non-Internet protocol, the gateway in turn communicating a termination command to the 
specified remote device using the internet protocol. 

30. (New) A method according to claim 12, wherein the identification of the 

receiver/decoder is authenticated by the gateway before the communication channel is 
established. — 

Please cancel claims 26-28. 

IN THE ABSTRACT 

N Please replace the Abstract with the following paragraph [a marked-up copy of the 

jj amended Abstract is attached in Appendix B] : 

si 

ff, ~A method of authenticating communication between a receiver/decoder and a 

g * remote server is disclosed. The method includes using an identifier of the receiver/decoder to 

a 

|4 authenticate the communication, the identifier being based on a smartcard number. Also 

Q 

45 disclosed is a gateway which is adapted to receive data from a receiver/decoder, which data are 

CI 

ft? not in internet protocol, and to convert said data into internet protocol for transmission to an 
internet service provider. - 

REMARKS 

The claims have been amended to remove multiple dependencies and to provide 
proper antecedent basis. New claims 29 and 30 have been added to the application and are fully 
supported by original claims 16 and 17, respectively. No amendments have been made for 
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reasons relating to patentability, and no new matter has been introduced by way of this 
amendment. The Abstract has been amended to correct formalities. Full examination and 
favorable action are requested. 

Please apply any charges not covered, or any credits, to Deposit Account 50-0591 
(Reference No. 11345.042001). 



Respectfully submitted, 





Jonathan P. Osha, Reg. No. 33,986 
Rosenthal & Osha L.L.P. 
1221 McKinney, Suite 2800 
Houston, TX 77010 



Telephone: (713) 228-8600 
Facsimile: (713)228-8778 
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APPENDIX A - MARKED-UP VERSION OF THE AMENDED CLAIMS 

3. (Amended) A method according to Claim 1[ or Claim 2] wherein the identifier is 
independent of a network login identifier for the receiver/decoder. 

4. (Amended) A method according to [any preceding JclaimJ, wherein the identifier is 
based on a number unique to a smartcard for use with the receiver/decoder. 

5. (Amended) A method according to [any preceding JclaimJ., wherein the remote 
server is for accessing the internet. 

j4 6. (Amended) A method according to [any of Claims 1 to 41 claim 1. wherein the 

a 

Q remote server is an internet account management system. 

U 

iff 

h 9. (Amended) A method according to Claim 7[ or Claim 8], wherein the remote server 

m comprises means for sending data to an internet service provider and wherein said method 

Q comprises the steps of providing details of the internet account to the internet service provider to 

M 

Q establish a bi-directional data pathway between the receiver/decoder and the internet service 

0 provider. 

w 

10. (Amended) A method according to [any preceding JclaimJ., wherein said identifier 
is accompanied by data identifying a data pathway to be used for communication between the 
receiver/decoder and the remote server. 

11. (Amended) A method according to [any preceding JclaimJ,, wherein the remote 
server provides the receiver/decoder with access to a network having network protocols, and data 
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output from the receiver/decoder is converted into data compliant with the network protocols at a 
location remote from the receiver/decoder. 

14. (Amended) A method of communicating data from a non-internet protocol enabled 

user terminal to one of a plurality of internet protocol enabled remote devices, the method 
comprising the steps of: 

communicating data using said non-internet protocol from said user terminal to 
a[said] gateway, said data including a message and specifying a destination for said message 
from said plurality of remote devices; and 

converting at said gateway said data into data using said internet protocol; and 

communicating said data using said internet protocol from said gateway to the 
specified destination remote device, thereby establishing a communication channel between the 
user terminal and the specified remote device. 

16. (Amended) A method according to [Claim 13 or ] Claim 15, wherein a message 
instructing termination of the communication channel is communicated from the 
receiver/decoder to the gateway using the non-internet protocol, the gateway in turn 
communicating a termination command to the specified remote device using the internet 
protocol. 

17. (Amended) A method according to [any of Claims 12, 13, 15, and 16] claim 15, 
wherein the identification of the receiver/decoder is authenticated by the gateway before the 
communication channel is established. 
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20. (Amended) Apparatus according to Claim 18[ or Claim 19], wherein the remote 
server provides the receiver/decoder with access to a network having network protocols, said 
apparatus comprising means for converting data output from the receiver/decoder into data 
compliant with the network protocols. 

21. (Amended) Apparatus according to [any of Claims 18 to 201 claim 18 , comprisingfin 
the form of] a gateway intermediate the receiver/decoder and the remote server. 

25. (Amended) A gateway according to Claim 23 [ or 24], comprising: 

means for identifying a message from the user terminal instructing termination of the 
m communication channel; and 

Q 

63 means for passing a termination command to the specified remote device. 

H 
II 

| 
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M 
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APPENDIX B - MARKED-UP VERSION OF THE AMENDED ABSTRACT 

A method of authenticating communication between a receiver/decoder and a remote 
server is disclosed. The method includes [comprises] using an identifier of the receiver/decoder 
to authenticate the communication, the identifier being based on a smartcard number. Also 
disclosed is a gateway which is adapted to receive data from a receiver/decoder, which data are 
not in internet protocol, and to convert said data into internet protocol for transmission to an 
internet service provider. 
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COMMU NICATI ON METHO DS AND APPARATUS 

The present invention relates to methods and apparatus for communication between 
a user unit, such as a receiver/decoder, and a remote unit, which may be, for example, 
5 an internet account management system or an internet service provider. 

Receiver/decoders are used for receiving and/or decoding signals, such as television 
signals, which may be transmitted in analogue or digital form. In the case of digital 
transmission, digital channels are encoded into a digital data stream at the transmitter 
10 end, and are decoded at the receiver end using a receiver/decoder, which may be either 
in a digital set-top box (DSTB) or in an integrated digital television. In the case of 
analogue transmission, a receiver/decoder may be provided at the subscriber to convert 
the transmitted signals into a format that may be displayed on a television screen. 

15 Receiver/decpders typically contain a processor on which programs known as 
applications may be run. An example of an application which may be run on a 
receiver/decoder is an internet access application, which can allow a subscriber to 
access the internet by means of the receiver/decoder. 

20 Receiver/decoders tend to be of relatively simple construction in order to ensure a low 
unit cost. This can make it difficult to set up a receiver/decoder to communicate with 
a remote network, such as the internet. In particular, communication with the internet 
requires the use of internet protocols and authentication which may be difficult to 
implement on a receiver/decoder. For example, certain receiver/decoders may not be 

25 able to output data in a format suitable for direct connection to the internet. Such 
receiver/decoders are referred to as "non-IP enabled". 

A first aspect of the present invention provides a method of authenticating 
communication between a receiver/decoder and a remote server for providing access 
30 to a network, the method comprising using an identifier of the receiver/decoder to 
authenticate the communication, the identifier being based on an identifier for access 
to broadcast services. 

By use of the invention, authentication of the communication between the 
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receiver/decoder and the remote server can be based on a unique identifier of the 
receiver/decoder to which the receiver/decoder has ready access, which can reduce the 
requirements made of the receiver/decoder. Receiver/decoders are often provided with 
a unique identifier for access to broadcast services, which identifier provides a 
5 convenient means of identifying the receiver/decoder. 

Preferably the identifier is stored on a removable component, such as a smartcard. 

Preferably the identifier is independent of a network login identifier. This can reduce 
the complexity of the receiver/decoder, since the identifier may be simpler than a 
network login identifier, which tend to be complex multicharacter identifiers, to 
facilitate memorising by a user. Another drawback with login identifiers is that they 
may change from time to time, or more than one may be required for access to 
different services; the invention may allow a single identifier supplied by a 
receiver/decoder to be associated (in a remote server) with a changeable network 
identifier or with a plurality of network identifiers. This feature may be provided 
independently. 

Preferably the identifier is based on a number unique to a smartcard. As used herein, 
ri 20 the term "smartcard" includes, but not exclusively so, any chip-based card device, or 

5 * object of similar function and performance, possessing, for example, microprocessor 

and/or memory storage. Included in this term are devices having alternative physical 
forms to a card, for example key-shaped devices such as are often used in TV decoder 
systems. 

25 

The remote server may be for accessing the internet, or it may be an internet account 
management system, or any other form of server, for example, for accessing a remote 
network of any form. 

30 An internet account for a user may be established by an internet account management 
system using the identifier of the receiver/decoder. To establish the account, the 
identifier of the receive/decoder may be compared by the internet account management 
system with a stored list of identifiers of receiver/decoders which may establish 
internet accounts. 

i 
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The remote server may comprise means for sending data to an internet service 
provider, the method comprising the steps of providing details of the internet account 
to the internet service provider to establish a bi-directional data pathway between the 
receiver/decoder and the internet service provider. 

5 

The identifier may be accompanied by data identifying a data pathway to be used for 
communication between the receiver/decoder and the remote server. In this way the 
receiver/decoder can specify the pathway to be used for communication; for example 
a satellite link may be used for the return channel. 

10 

In a preferred embodiment, the login details are in the form: 

login = {smartcard number} {type of services} 
where the type of services (TOS) may specify the channels over which data 
communication is to occur, for example, the case where a category of responses are 
to be sent to the terminal by satellite. 

In a preferred embodiment, the remote server provides the receiver/decoder with 
access to a network having network protocols, and data output from the 
receiver/decoder is converted into data compliant with the network protocols at a 
location remote from the receiver/decoder. In this way, a receiver/decoder which is 
not equipped with the network protocols may still communicate with the network. 
The network may be, for example, the internet, and the network protocol may be, for 
example, transport control protocol / internet protocol (TCP/IP). The remote location 
may be, for example, at an operator, which may comprise an internet account 
management system. 

Preferably, the data is converted into said data compliant with the network protocols 
by a gateway intermediate the receiver/decoder and the remote server. 

In a preferred embodiment, the network comprises a plurality of remote devices, said 
converted data being communicated by the gateway to one of said remote devices as 
specified in said data thereby establishing a communication channel between the 
receiver/decoder and the specified remote device. 
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In a second aspect, the present invention provides a method of communicating data 
from a non-internet protocol enabled user terminal to one of a plurality of internet 
protocol enabled remote devices, the method comprising the steps of communicating 
data using said non-internet protocol from said user terminal to said gateway, said 

5 data including a message and specifying a destination for said message from said 
plurality of remote devices, converting at said gateway said data into data using said 
internet protocol, and communicating said data using said internet protocol from said 
gateway to the specified destination remote device, thereby establishing a 
communication channel between the user terminal and the specified remote device. 

0 The user terminal may be a receiver/decoder. 

Also provided is a method of communicating between a receiver/decoder and a 
remote network wherein the protocols necessary for communicating with the remote 
network are implemented at a remote location from the receiver/decoder. 

5 

A message instructing termination of the communication channel may be 
communicated from the receiver/decoder to the gateway using the non-internet 
protocol, the gateway in turn communicating a termination command to the specified 
remote device using the internet protocol. Preferably, the identification of the 
0 receiver/decoder is authenticated by the gateway before the communication channel 
is established. 

In a third aspect, the present invention provides apparatus for authenticating 
communication between a receiver/decoder and a remote server for providing access 
5 to a network, the apparatus comprising means (for example, a system, server or 
gateway) for using an identifier of the receiver/decoder to authenticate the 
communication, the identifier being based on an identifier for access to broadcast 
services. The identifier may be accompanied by data identifying a data pathway to 
be used for communication between the receiver/decoder and the remote server. 

0 

The remote server may provide the receiver/decoder with access to a network having 
network protocols, said apparatus comprising means (for example, a system, server 
or gateway) for converting data output from the receiver/decoder into data compliant 
with 
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the network protocols. 

Preferably the apparatus is a gateway intermediate the receiver/decoder and the remote 
server. 

Preferably the network comprises a plurality of remote devices, said gateway being 
adapted to communicate the converted data to one of said remote devices as specified 
in said data thereby establishing a communication channel between the 
receiver/decoder and the specified remote device. 

In a fourth aspect, the present invention provides a gateway for communicating data 
received from a non-internet protocol enabled user terminal to one of a plurality of 
internet protocol enabled remote devices, the gateway comprising: 

means (for example, an input) for receiving data communicated using said non- 
internet protocol from said user terminal, said data including a message and specifying 
a destination for said message from said plurality of remote devices; and 

means (for example, a converter) for converting the received data into data 
using said internet protocol; and 

means (for example, an output) for communicating said data using said internet 
protocol to the specified destination remote device, thereby establishing a 
communication channel between the user terminal and the specified remote device. 

The gateway may comprise a plurality of input/output ports each for connection to a 
respective remote device. 

The gateway may comprise means (for example, an identifier) for identifying a 
message from the user terminal instructing termination of the communication channel; 
and means (for example, an output) for passing a termination command to the 
specified remote device. 

The invention also provides a method and apparatus substantially as described with 
reference to and as illustrated in the accompanying drawings. 

Features of one aspect may be applied to other aspects; similarly, method features may 
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be applied to apparatus aspects and vice versa. 

Preferred features of the present invention will now be described, purely by way of 
example, with reference to the accompanying drawings, in which:- 

5 

Figure 1 shows the architecture of a typical digital television system; 
Figure 2 is a schematic diagram of a receiver/decoder; 
Figure 3 shows an overview of an internet access system; 
Figure 4 illustrates software layers in the user equipment of Figure 3; 
10 Figure 5 shows the architecture of an internet access system; 

Figure 6 shows the main components of an internet account management 

system; 

Figure 7 shows a part of the configuration of the internet access system in the 
case where the receiver/decoder is not IP enabled; 



15 Figure 8 illustrates protocol layers of the system shown in figure 7; 

rg Figure 9 diagrammatically illustrates the protocol adopted for communication 

between the user equipment and the gateway in the system of figure 7; and 

Q Figure 10 diagrammatically illustrates the protocol adopted for authentication 

t-! related communication between the user equipment and the gateway in the system of 

20 figure 7. 

P 

■ ny . 

An overview of a digital television system 1 is shown m Figure 1. The invention 
includes a mostly conventional digital television system 2 that uses the known MPEG- 
2 compression system to transmit compressed digital signals. In more detail, MPEG-2 
25 compressor 3 in a broadcast centre receives a digital signal stream (typically a stream 
of video signals). The compressor 3 is connected to a multiplexer and scrambler 4 by 
linkage 5. 

The multiplexer 4 receives a plurality of further input signals, assembles the transport 
30 stream and transmits compressed digital signals to a transmitter 6 of the broadcast 
centre via linkage 7, which can of course take a wide variety of forms including 
telecommunications links. The transmitter 6 transmits electromagnetic signals via 
uplink 8 towards a satellite transponder 9, where they are electronically processed and 
broadcast via notional downlink 10 to earth receiver 12, conventionally in the form 
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of a dish owned or rented by the end user. Other transport channels for transmission 
of the data are of course possible, such as terrestrial broadcast, cable transmission, 
combined satellite/cable links, telephone networks etc. 

5 The signals received by receiver 12 are transmitted to an integrated receiver/decoder 
13 owned or rented by the end user and connected to the end user's television set 14. 
The receiver/decoder 13 decodes the compressed MPEG-2 signal into a television 
signal for the television set 14. Although a separate receiver/decoder is shown in 
Figure 1, the receiver/decoder may also be part of an integrated digital television. 
10 As used herein, the term "receiver/decoder" includes a separate receiver/decoder, 
such as a set-top box, and a television having a receiver/decoder integrated therewith. 

In a multichannel system, the multiplexer 4 handles audio and video information 
received from a number of parallel sources and interacts with the transmitter 6 to 
15 broadcast the information along a corresponding number of channels. In addition to 
audiovisual information, messages or applications or any other sort of digital data 
may be introduced in some or all of these channels interlaced with the transmitted 
digital audio and video information. 

20 A conditional access system 15 is connected to the multiplexer 4 and the 
receiver/decoder 13, and is located partly in the broadcast centre and partly in the 
receiver/decoder. It enables the end user to access digital television broadcasts from 
one or more broadcast suppliers. A smartcard, capable of deciphering messages 
relating to commercial offers (that is, one or several television programmes sold by 

25 the broadcast supplier), can be inserted into the receiver/decoder 13. Using the 
receiver/decoder 13 and smartcard, the end user may purchase commercial offers in 
either a subscription mode or a pay-per-view mode. 

As mentioned above, programmes transmitted by the system are scrambled at the 
30 multiplexer 4, the conditions and encryption keys applied to a given transmission 
being determined by the access control system 15. Transmission of scrambled data 
in this way is well known in the field of pay TV systems. Typically, scrambled data 
is transmitted together with a control word for descrambling of the data, the control 
word itself being encrypted by a so-called exploitation key and transmitted in 
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encrypted form. 

The scrambled data and encrypted control word are then received by the 
receiver/decoder 13 having access to an equivalent to the exploitation key stored on 
5 a smart card inserted in the receiver/decoder to decrypt the encrypted control word 
and thereafter descramble the transmitted data. A paid-up subscriber will receive, for 
example, in a broadcast monthly EMM (Entitlement Management Message) the 
exploitation key necessary to decrypt the encrypted control word so as to permit 
viewing of the transmission. 

10 

An interactive system 16, also connected to the multiplexer 4 and the 
receiver/decoder 13 and again located partly in the broadcast centre and partly in the 
receiver/decoder, enables the end nser to interact with various applications via a 
modemed back channel 17. The modemed back channel may also be used for 
15 communications used in the conditional access system 15. 

Physical interfaces of the receiver/decoder 13 are used for downloading data. With 
reference to Figure 2, the receiver/decoder 13 contains, for example, six downloading 
devices; serial interface 30, parallel interface 32, modem 34, two card readers 36, 
20 and MPEG flow toner 38. 

The broadcast and reception system is also used to provide internet services such as 
web browsing and e-mail. An application which is run by the receiver/decoder 13 
enables the receiver/decoder to access internet services and to display web pages and 
25 e-mails either on television set 14 or via a computer connected to the receiver/decoder 
13. 

Referring to Figure 3, an overview of the internet access system will be described. 
User equipment 20 (which includes a receiver/decoder) communicates with operator 
30 22 via the public switched telephone network (PSTN) 24. The user equipment sends 
a request to the operator 22 to be sent certain data, for example, a particular web page 
or e-mail. The operator receives this request and outputs the request to internet 
service provider (ISP) 26. In response to this request, the ISP supplies a response to 
the operator, which might comprise a requested web page obtained from the internet 
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27, or an e-mail which was waiting for the subscriber at the ISP. The operator 
delivers the response to the broadcast centre 28, where it is integrated into the MPEG 
bitstream, for example as a private section, and transmitted by the transmitter 6 and 
received by receiver 12 as previously described. Where the receiver/decoder is IP- 
5 enabled, i.e. equipped with the protocols for receiving data from the internet, the 
information may be transmitted as an IP frame in the MPEG bitstream, that is, in the 
IP format. If the receiver/decoder is not IP-enabled then the data is sent in some other 
way, e.g. as a private MPEG section. The user equipment 20 extracts the response 
from the MPEG bitstream and displays it on a television set or on a computer screen. 
10 The response may alternatively be transmitted to user equipment 20 via the PSTN 24. 

The software levels employed in the user equipment 20 are shown in Figure 4. The 
application level comprises a web browser and e-mail application, which may be a 
commercial application such as Netscape or Microsoft Internet Explorer and Outlook 

15 Express, or an application specifically designed to run on a receiver/decoder. Below 
the application level are HTTP, socket, TCP/IP, PPP/SLIP and a driver level. The 
driver level is modified, as compared with a browser application running traditionally 
on a PC, in that it is divided into a modem driver for communicating with the PSTN 
24 via the modem of the user equipment and a tuner driver for communicating via the 

20 MPEG flow tuner 4028. 

Various configurations of the user equipment 20 are possible. In one configuration a 
PC is not used and all of the user software runs on the receiver/decoder 13. In this 
configuration the receiver/decoder 13 communicates with the PSTN 24 either via an 

25 internal modem or via an external modem and the serial port. The receiver/decoder 13 
can receive Internet responses in the bitstream from the earth receiver 12. The user 
interface is provided by a remote controller or keyboard and a television set connected 
to the receiver/decoder 13. In this configuration, the TCP/IP level shown in Figure 
4 may be omitted, in which case a gateway located at the operator provides the 

30 necessary protocols, as will be described later. 



In another configuration a personal computer (PC) is provided which is connected by 
its parallel port to the parallel port 32 of the receiver/decoder 13 (or optionally by its 
serial port to the serial port 30 of the receiver/decoder 13). In this case, an upper 
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portion of the software levels shown in Figure 4 run on the PC, and the remaining 
lower portion of the software levels run on the receiver/decoder 13. The user interface 
is provided by a keyboard and a monitor connected to the PC. 

5 In a further configuration a PC is connected to the PSTN 24 via an internal or external 
modem of the PC. In this configuration, the receiver/decoder 13 may be provided 
separately or in the form of an add-on or plug-in card of the PC, connected to the ISA 
or PCI bus thereof. 



10 The architecture of the internet access system is shown in Figure 5. Referring to 
Figure 5, internet account management system (IAMS) 50 is linked to internet service 

M provider (ISP) 26 which provides services such as web browsing and e-mail. The 

fi 

3 IAMS 50 is also linked to subscriber management system (SMS) 60 which manages 

H subscribers and sends requests to the IAMS to grant or deny access to internet 
^ 15 services. Receiver/decoder 13 is connected to the IAMS via an internal modem, the 

Si public switched telephone network (PSTN) 24, network access server (NAS) 56, and 

s gateway 58. 

M 

Q The SMS is also connected to Subscription Authorisation System (SAS) 61, which 

20 manages authorisations and subscribers' orders for broadcast services, such as 

-5 broadcast television services. The SMS runs the SAS and IAMS systems in parallel 

and ensures consistency between the two systems. Communication between the SMS 
and the SAS and IAMS takes place using a real time TCP/IP link using batch files. 

25 Gateway 58 allows subscribers to access internet services in real time. Such services 
include mail services for sending and receiving mail and other services which may 
be provided by ISP 26, and provisioning services and reminder services, which are 
provided by the IAMS. Functionally, the gateway 58 is a message router that enables 
communication with various different systems in a single modem connection. Where 

30 the receiver/decoder is not equipped with TCP/IP protocols for communicating with 
the ISP, the gateway also provides the necessary protocols for the receiver/decoder 
to communicate with the ISP. The receiver/decoder 13 then communicates with the 
ISP via gateway 58, as indicated by line 59 in Figure 5. Where the receiver/decoder 
is equipped with the necessary protocols, communication can take place with the ISP 
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directly, as indicated by dashed line 57 in Figure 5. The gateway comprises a 
communication server and an e-mail dispatcher. 

ISP interface 66 allows each modification related to a user's account which takes place 
5 in the IAMS to be duplicated to a user account in ISP 26 in charge of hosting internet 
services, such as mail services. It should be noted that all information relating to 
subscriber accounts is centralised in the IAMS, which ensures the management of TV 
and internet parameters. The IAMS also manages the relationship between the internet 
parameters and TV parameters, through its interface with Subscriber Management 
10 System (SMS) 60. SMS 60 manages subscribers and sends requests to the IAMS in 
order to grant or to deny access to internet services by subscribers. 

In order to set up an IAMS account, a subscriber first sends a request for a new 
account, together with information such as requested e-mail address and selected 

15 options, from the receiver/decoder 13 to the IAMS 50. The IAMS checks the 
smartcard number of the subscriber against a list of smartcard numbers, obtained from 
subscriber management system (SMS) 60, corresponding to subscribers for which it 
may set up internet accounts. The IAMS then sends a request to the ISP to set up an 
internet account. Once the account has been set up, the ISP returns an 

20 acknowledgement to the IAMS, together with a password. The password is initially 
defined by the SMS, but may be modified later by the subscriber. The IAMS account 
information (password, e-mail address and internet parameters), is stored in the IAMS, 
along with the smartcard number of the subscriber. The IAMS informs the subscriber 
that his account has been set up. The subscriber can then send and receive mail to and 

25 from the mail server 28. 

The main components of the IAMS are shown in Figure 6. The main functions of the 
IAMS are as follows: 

o maintaining a centralised list of e-mail account parameters linked to 
30 subscriber parameters such as smartcard number 

o granting or denying access to internet services for a subscriber at the request 

of the SMS 

o customising internet accounts at the request of subscribers (provisioning) 
o reminder service, which allows an e-mail user to register an event and to 
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be warned by an e-mail at the time of the event 

o duplication service, which allows updates of the IAMS contents to be 
copied to a related server, such as an ISP 

5 Central to the IAMS is a relational database management system (RDBMS) 70, which 
contains subscription information for internet services and e-mail accounts, stored in 
storage means 72. SMS communication interface 74 allows the IAMS to communicate 
with the SMS, so that the IAMS may be updated with the details of subscribers who 
have been granted or denied access to mail services. Provisioning server 76 allows 

10 a subscriber to manage and customise his e-mail account. Reminder server 78 allows 
a subscriber to manage a list of events. An event is related to a subscriber's e-mail 
account. A subscriber may register an event and receive an automatic reminder a 
predetermined number of days before the event via an automatically generated e-mail. 
E-mail notification interface 84 allows the EMNS 62 to search for a subscriber's 

15 notification preferences in the IAMS RDBMS 70 in order to send an over air 
notification message. Support server 80 allows an administrator to check the presence 
and the status of a subscriber or an e-mail user in the IAMS. Replication service 82 
copies updates of the contents of the IAMS RDBMS 70 to the ISP account 
management system. 

20 

Requests which are sent to the IAMS from receiver/decoder 13 are directed to the 
appropriate part of the IAMS, such as the provisioning server (for e-mail account 
management) and the reminder server (to manage reminder events), by the gateway 
58. 

25 

The internet access system described above allows broadcast service providers also to 
provide internet services. The operator of the system maintains internet accounts 
independently of internet service providers, so that the operator is not tied to a 
particular internet service provider. By linking together subscriptions to broadcast 
30 services and subscriptions to the internet, accounts for the two services may be 
managed together which may reduce the amount of processing involved, in comparison 
to the case where accounts are managed separately, and the subscriber may be billed 
together for the two services. 
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Further details of the IAMS are described in co-pending patent application entitled 
"Internet Subscriber Management" in the name of the present applicant, the subject 
matter of which is incorporated herein by reference. Further details of the e-mail 
notification system are described in co-pending patent application entitled "Method 
5 and Apparatus for use with E-mail" in the name of the present applicant, the subject 
matter of which is incorporated herein by reference. 

A configuration of the internet access system in the case where the receiver decoder 
13 is not internet enabled will now be described with reference to Figures 7 to 10. 

10 Referring to Figure 7, which shows a portion of the system shown in its entirety in 
Figure 5 but with certain aspects delineated in greater detail, receiver / decoder 13 
is of the type previously described in which the unit is not equipped with the transport 
control protocol / internet protocol (TCP/IP) necessary for direct communication with 
the ISP 26. Communication, therefore, takes place via DSTB Gateway 58. The 

15 Provisioning server 76 and Reminding server 78 are shown in the figure as distinct 
portions of the IAMS 50 and, in the embodiment, data is routed to each via separate 
lines 76a and 78a as appropriate. 

It will be appreciated, therefore, that there are in effect four subsystems of interest 
20 in any communication between the receiver / decoder 13 and any remote server 
desired to be accessed. These are the receiver / decoder 13 itself, the NAS 56, the 
Gateway 58 and the remote server which in the embodiment may be any one of 
provisioning server 76, reminding server 78 or mail server 64. The PSTN 24 is 
effectively data transparent. In the embodiment mail server 64 is accessed via 
25 interface 66 and the ISP 26 but this need not be the case and the mail server 64 could 
be directly accessed from the Gateway 58. Moreover, although shown as a single 
unit in the figure, the mail server 64 may consist of two separate units, a first for 
sending emails (which may be for example a SMTP server) and a second for 
receiving emails (which may be for example a IMAP server). In such an 
30 configuration, the Gateway 58 may communicate with the two units which comprise 
the mail server via two separate ports. 

The different protocol levels handled by each of the four above described sub-systems 
will now be described with reference to figure 8. As will be seen from the figure, 
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the receiver / decoder 13 has four protocol levels as follows (highest level first): an 
application level protocol (which will be application dependent) and may, for 
example, be SMTP, IMAP or the like; a Gateway protocol (this being the level used 
for the receiver / decoder - Gateway communication as will be more fully described 
5 below); a PP4 protocol and a modem layer such as v22 or v42 bis. The operation 
of these latter two layers will be well known to the skilled person. 

The NAS 56 functions at a single protocol layer and is effective to convert the 
modem layer (used to communicate across the PSTN 24) to internet protocol TCP/IP. 

0 

The Gateway 58 has three operative protocol layers (again highest first), namely the 
Gateway protocol layer, the PP4 protocol layer and TCP/IP. 

Finally the remote server will generally have two protocol layers an upper layer at 
5 the application level protocol and a lower layer at TCP / IP protocol. 

The Gateway protocol therefore allows the Gateway 58 to respond to messages and 
in appropriate cases identify the intended recipient of data and forward the data to that 
recipient. The protocol also allows the receiver / decoder 13 to initiate various 

0 Gateway 58 / remote server operations. In the embodiment, the Gateway 58 is 
responsible for directing SMTP or IMAP data to the mail server 64; directing data 
to provisioning server 76 which may include requests to provide for the creation of 
new accounts; directing data to the reminder server 78 which may include requests 
for event registration; constructing messages to be sent to the receiver / decoder 13 

5 on the basis of data received from any one of the mail server 64, the provisioning 
server 76 or the reminder server 78 and handling the communication of such 
constructed messages. In addition the Gateway has the ability to perform a receiver 
/ decoder authentication function. 

D The low level communication between the receiver / decoder 13 and the Gateway 58 
will now be described. As a first step, modem communication is established between 
the receiver / decoder 13 and the NAS 56 over PSTN 24. Any suitable modem 
format may be used, for example v22 or v42bis. At this time a "chat" sequence 
occurs at the modem level between the receiver / decoder 13 and the NAS 56 so as 
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fully to establish the communications channel. Thereafter the NAS 56 establishes a 
connection channel with the Gateway 58 at the TCP protocol level. Following this 
event, a token is sent by the Gateway 58 to the receiver / decoder 13, this token 
being a pre-specified character sequence. The receipt of such a token by the receiver 
5 / decoder 13 notifies it of the presence of the Gateway 58 and a communications 
channel between the receiver / decoder 13 and the Gateway 58 at the gateway 
protocol level is thereby established. 

The established gateway protocol communications channel is, in effect, under the 
10 control of the receiver / decoder 13. It is the receiver / decoder which must request 
the channel before message exchange can occur. Additionally the disconnection 
procedure (described below) is instigated by the receiver / decoder 13 in order to 
close the channel. 

15 It should be noted that, in this embodiment, the gateway protocol allows the 
establishment of a single TCP channel with a corresponding remote server. In other 
words, in this embodiment, the receiver / decoder 13 cannot be connected to more 
than one remote server at any one time. However, the receiver / decoder 13 may 
establish and release connection to different remote servers without needing to 

20 establish a fresh communications channel between it and the Gateway 58. 

It should further be noted that, in the embodiment, the gateway protocol layer does 
not perform any error recovery function since the lower level protocols (modem / 
TCP) ensure the transport of data and the upper level protocols (application protocols) 
25 perform error handling. 

The general message structure of communications in the Gateway protocol will now 
be described. Each message structure contains the following fields: 

30 {protocol version} {command identifier} {data length} [parameters] 

where {...} indicates mandatory fields and [...] optional fields. 

The message structure is the same regardless of whether .the message emanates from 
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the receiver / decoder 13 or the Gateway 58. The fields are binary encoded with the 
most significant bit first. 

The protocol version (PRT) field comprises a single byte identifying the protocol 
5 version. 

The command identifier (CI) field comprises two bytes and identifies the type of 
message represented. The various types of message will become apparent from the 
data exchange events descriptions outlined below. 

10 

The data length (DL) field is two bytes in length and identifies the overall length of 
the appended parameters field (if any). This permits the parameter field to be of 
variable length. If there are no appended parameter fields, this field will contain a 
zero value. 

15 

The parameters field is encoded in TLV form (Type Length Value) and contains any 
necessary parameters associated with the message. There are three categories of 
parameter which may be used either individually or in combination dependent upon 
the type of message. In other words the type of message defines which of the 
20 parameter fields will be present. It will also be appreciated that certain messages (for 
example a message commanding that the connection be reset (MG_RCNX)) may not 
have an associated parameter. 

The first type of parameter (REMOTE_SERVER) is used to identify the remote 
25 server and contains an integer indicative of whether the server identified is the STMP 
portion of the mail server 64, the IMAP portion of the mail server 64, the 
provisioning server 76 or the Reminder server 78. In the embodiment, this parameter 
is two bytes long. In a modification the parameter could be used to identify other or 
additional servers. 

30 

The second type of parameter (BODY) is used to contain data received from or to be 
sent to a remote server of interest. This parameter is of variable length as defined 
by the data length field hence meaning that the data packages need not be of pre- 
determined length. A maximum length of this parameter is predefined. 
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The third type of parameter (ERRORCODE) is used to identify an error condition. 
This may be used to indicate, for example, when the Gateway is unable to open a 
connection with the specified remote server, when connection has been lost with the 
remote server, when a error is detected in a message received from the receiver / 
5 decoder 13, when no data has been received from a remote server following a 
command from the receiver / decoder 13 or when authentication has failed. In the 
embodiment, this parameter is two bytes in length. 

In a modification, there may be a fourth type of parameter used to contain 
10 authentication details. 

A typical data exchange sequence representative of normal dialogue over the Gateway 
protocol level communications channel will now be described with reference to Figure 
9. This shows diagrammatically the messages between the receiver / decoder 13 and 
15 the Gateway 58 together with the corresponding events occurring between the 
Gateway 58 and a selected remote server over a time period (time increasing down 
the page). 

The first event series (el) shown is the gateway protocol level connection procedure 
20 between the receiver / decoder and the specified remote server. The receiver / 
decoder 13 sends a message 1000 requesting connection (MG_CNX) containing two 
parameters, a REMOTESERVER parameter specifying the server to which it desires 
to conduct a dialogue and a BODY parameter which encapsulates data addressed to 
the remote server (if any). This causes the Gateway to perform two tasks collectively 
25 designated connection 1001 on the Figure, namely to establish connection with the 
specified server via the appropriate link and send via that link to the specified server 
the data (if any) contained in the message BODY parameter. 

Following the above sequence, the remote server sends data 1002 to the Gateway 58 
30 for onward transmission to the receiver / decoder 13. The Gateway encodes this in 
a "data exchange with remote server" (MG_REMOTE) message 1003, having a single 
parameter field, namely BODY which contains this data and sends the message to the 
receiver / decoder 13. A connection is thereby established. 
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The second event series (e2) shown is a typical data exchange sequence. The 
sequence commences with the sending by the receiver / decoder 13 of a "data 
exchange with remote server" (MG OTHER) message which contains data destined 
for the server in the field parameter BODY. As will be appreciated, the receiver / 
5 decoder 13 only communicates with one remote server at any one time and hence as 
the server will have been already specified by the connection message (e2), it does 
not require to be specified during ordinary data exchange. The receipt of this data 
exchange message 1004 by the Gateway 58 causes it to pass the data therein to the 
remote server in the communication designated 1005. 

10 

The remote server may, thereafter, send data to the receiver / decoder (designated 
1006, 1007) as previously described. 

A further feature of the embodiment will now be described with reference to the 

15 communications designated 1008a, 1008b and 1009. The "data exchange with remote 
server" (MG_REMOTE) message of the type sent from the Gateway 58 to the 
receiver / decoder 13 includes a minimum data packet size. The Gateway 58 will 
not, therefore, send a message to the receiver / decoder 13 until a pre-determined 
minimum amount of data has been received from the remote server (in effect a 

20 minimum data amount threshold) or until a predetermined time has elapsed from the 
receipt of the last data from the remote server (in effect a time out). Thus although 
communication 1008a represents data transfer from the remote server to the gateway 
58, the quantity of this data is lower than the predetermined threshold and hence no 
message is sent to the receiver / decoder 13 at this time. Next a further data transfer 

25 1008b between the occurs from the remote server to the Gateway 58. This transfer 
results in sufficient data being communicated to the Gateway and hence it sends a data 
exchange message 1009 which includes both data sequences 1008a, 1008b. In a 
similar manner, once the quantity of data received by the Gateway 58 from the 
remote server exceeds a maximum amount, a data exchange message is sent to the 

30 receiver / decoder 13. In such an event, a single data exchange sequence between 
the remote server and the Gateway 58 may result in plural messages between the 
Gateway 58 and the receiver / decoder 13. 

In the embodiment the timeout period is 200 milliseconds (ms), the minimum data 
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received threshold is 128 bytes and the maximum data received threshold is 512 
bytes. 

Although not shown in the figure, it may arise that the Gateway 58 receives no data 
5 from the remote server within a pre-determined timeout period which, in the 
embodiment, is 5 seconds. In such an event, the Gateway sends an "error detected 
by Gateway" (MGERROR) message to the receiver / decoder 13 which includes a 
parameter field of the ERROR_CODE type, the contents of this field specifying the 
occurrence of such an event. The receiver / decoder 13 is responsible for whatever 
10 further action it would like to take which may include the sending of a "reset 
communication" (MG_RCNX) message which causes the Gateway 58 to close the 
TCP connection with the remote server. 

As foreshadowed above, similar error messages may follow other events such as an 
15 inability to open a connection with the remote server, a loss of connection with the 
remote server or an erroneous message from the remote server. In the latter case this 
may include the receipt of data from the remote server by the Gateway 58 of an 
unknown type, of incorrect length, of an inapplicable value or having an unknown 
protocol version. 

20 

Returning to Figure 9, the event of disconnection from the remote server (e3) will 
now be described. This event is initiated by the receiver / decoder 13 sending a 
"disconnect" (MG_DCNX) message 1020. This message may include data to be 
passed to the remote server in a BODY parameter. This command and data 1021 is 

25 passed to the remote server and the Gateway 58 then waits for an acknowledgement 
and reply data 1022 if any. Subsequently, the Gateway 58 disconnects from the 
remote server (1023) and sends a message 1024 to the receiver / decoder 13 which 
includes the received data if any. Although not shown in the figure at the low 
protocol level, the receiver / decoder 13 may then close the connection at modem 

30 level. The Gateway 58 will thereafter be notified by the NAS 56 that the TCP 
connection is closed. 

The authentication process provided for by the Gateway protocol will now be 
described with reference to Figure 10. This may be required for various services, 
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for example provisioning services, before establishment of a communications channel. 
The Gateway 58 contains information upon which servers require authentication prior 
to access and when it receives a "connection request" (MG_CNX) message 1100 for 
such a server it responds with an "authentication request" (MG_AUTHEB_REQ) 
5 message 1101. Such an authentication request message has no accompanying 
parameters. The receiver / decoder 13 must thereafter respond with an appropriate 
"authentication" message 1102. This message has an associated parameter which 
includes authentication data which may, for example, be the smartcard number, as 
more fully set out below. The authentication data may be passed in a BODY type 
10 parameter or, in a modification may have its own parameter type. 

If the Gateway 58 adjudges the authentication details to be correct then the 
authentication is successful (indicated graphically be event 1103) and the Gateway 58 
establishes a connection 1104 with the specified remote server. The Gateway 58 
reports that the authentication is successful by sending a data exchange message 1 106, 
which will include any data 1105 received from the remote server in response to the 
opening of the connection. In the case where authentication fails, an error message 
(MGJERROR) is sent which includes a parameter indicating such a failure as 
previously outlined. 

Retorning to the system shown in Figure 5, it is possible to identify two distinct types 
of "account" for the accessing of internet services and the like from receiver / 
decoder 13, namely a so-called "connection account" and a so-called "directory 
account" . Within every connection account there may exist plural directory accounts. 

A connection account provides the basis upon which a subscriber may access the 
operator network. A subscriber will be allocated a single connection account per 
operator although this may be associated with several connection protocols as more 
fully described below. The method by which authentication of such an account 
occurs is at the network level and will also be described in greater detail below. 

The procedure upon user login by means of his connection account will now be 
described. As will be appreciated, the identification data supplied upon log-in must 
be unique in order to permit the user to be identified by the recipient. In the 
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embodiment, this is achieved by the use of a so-called MSD number, which is at least 
partially derived from the smartcard number of the user's equipment. In addition, 
upon log-in, the user must specify the communications protocol which may vary in 
dependence upon, for example, whether the user is attempting access via a dial-up 
5 modem associated with a computer (which may use, for example, MediaWebPC a 
product of Canal +) or via the type of receiver / decoder unit such as that commonly 
referred to as a "set-top box". The protocols used may, for example, be PAP, CHAP 
or PPP for dial-up modem. 

10 The login information includes, therefore, of the MSD number of the user, a field 
identifying the type of user terminal, a field specifying the type of data return to be 
utilised, a field indicating the client version number and, if applicable, the so-called 
RADIUS domain name of the client. The login will also include a password. In the 
embodiment, this information is formatted as follows: 

15 

login = 

{msn_number} {terminal type} {returnjype} {version} [@RADIUS_domain_nameJ 
Each of the above fields will now be explained in fuller detail. 

20 

The msn_number field itself consists of the following string of fields: 
{msn_number} = {RSMC} {RSMN} {chck} 

25 The first of the MSN data fields contains the removable security module product code 
(RSMC) which identifies the type of smartcard. This identification of type may 
include data indicative of the one or more aspects of the technical make-up of the 
card, the manufacturer and the commercial operator who has provided the card to the 
user. In the embodiment, this field is of two bytes in length and may contain four 

30 digits. 

The second of the MSN data fields contains the removable security module number 
(RSMN). This field includes a code which identifies a smartcard in use. Such code 
is preferably pre-programmed by the smartcard supplier and is unique to the 
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smartcard and hence the user, thereby allowing identification of the user. In the 
embodiment this field is four bytes in length and may contain fifteen digits. 

The final field contains check data (chck) which may be calculated by any known 
5 method, for example, it may be a checksum. 

The terminal_type field will now be explained. As explained above, the terminal may 
be of the so-called "set-top" box variety or may be a computer having a modem 
facility. The field will take the value "P" for a PC type terminal and the value "T" 
10 for a set-top box terminal type. It will be appreciated that the field could, more 
precisely specify the terminal type and that the provision of such a field also permits 
future expansion by the definition of further and alternative terminal types. 

The returnjype field permits the specification of the method by which return data is 
15 sent to the user. In the embodiment, the field takes the value "M" when all return 
data is to be routed via the modem and the value "S" when data return is to take 
place over both satellite and modem channels. Again the possibility of future 
expansion in the methods of providing return data is provided for. 

20 The version data field allows version data to be passed from the receiver / decoder 
13 to the network. In the embodiment this is set at 01 as a default. 

The optional field RADIUS_domain_name permits a client's authentication request 
to be routed to a third part authentication server which may permit the provision by 
25 such a third party of gateways to, for example, different service provider. 

The connection profile will also contain a password field which, in the embodiment, 
has a maximum length of 14 alphanumeric characters. 

30 Return now to describe the directory account this provides the basis for the accessing 
of individual internet services, for example proxy with identification, mail, news et 
cetera. A subscriber's directory accounts are linked to his connection account. In 
distinction, however, to a connection account, authentication of a directory account 
occurs at application level. 
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As previously stated, the directory account allows the access to divers internet 
services from the receiver / decoder 13. A directory account will generally consist 
of: 



5 - an identifier and password; 

- one or more so-called "e-mail aliases"; 

- in appropriate cases, other data relating to the services offered to the 
subscriber. 



10 The identifer (in appropriate cases in combination with the password) is used to 
control the access by the subscriber of various ISP services, for example access to the 

H subscriber's mailbox. Other examples include access to private websites, directories, 

gj control of access to services, certificates, "mailgroup" registration and the like. 

14 

yp 

%j 15 The identifier may also be used to receive e-mails address in the format 



"identifier@domain", in which event the subscriber may need to use his password 
when accessing the mailbox identified by the identifier. 



p The e-mail aliases provide for the facility of e-mail receipt by the e-mail server of 

Jj 20 messages address to "alias@domain". 

I 

In an embodiment, several directory accounts may be associated with a single 
connection account (so-called "family subscription"). In such an event, it may be 
possible for a user initially to specify the number of directory accounts which are 
25 permissible for each connection account, although it should be noted that each 
identifier and alias must be unique. 



Terms 



The following terms are used herein: 



E-mail Address 



An E-mail address is composed of two fields: the E-mail ID 
and the domain name. The form of an e-mail Address is e- 
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E-mail Account 
E-mail Id 

5 

E-mail Notifier 



Internet Account 
10 Management System 

Mailbox 

15 



Mail Server 

20 Message Queue 
Server (MQS) 
Provisioning 
Server 

25 Reminder Server 

Set Top Box 

30 



SmartCard 
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maii_Id@Domain_Name . 

An E-mail Account provides information about the user that 
a Mail Server needs to process that user's messages. 
The prefix of an e-mail address. An e-mail Id is unique in a 
domain name. 

The e-mail Notifier System allows subscribers (EMN) to be 
notified as soon as they receive a new e-mail in their 
mailboxes. A short message is sent to their STB over-air. 

A system managing subscriber TV account Management 
parameters and related E-mail Accounts System (IAMS) 
parameters 

Messages stored for IMAP delivery are held in a mailbox. A 
mailbox on a mail server must be uniquely identified by a 
mailbox Id. A mail server hosting different domain name can 
not consider that the e-mail Id is unique on the Mail server, so 
the mailbox Id must be the Email address. 
Program that exchanges e-mail with other Mail Servers and 
accepts and delivers messages to mail clients. 

A message management system. 

Allows subscribers to create and customise e-mail accounts 
themselves. 

Allows a user to register an event and receive an automatic 
reminder via an automatic mail. 

The completely assembled, ready to use (STB) digital decoding 
hardware, manufactured in accordance with Digital Video 
Broadcasting standards, CANAL + TECHNOLOGIES 
specifications. It is used as a digital decoder for transmitted 
video, audio, application and data streams so that the end user 
can access television programs and services. 
Cards that electronically store the secret keys of one or more 
commercial operators and other access information. 
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SmartCard Cards that electronically store the secret keys of one or more 

commercial operators and other access information. 

Subscriber A subscriber is related to a TV account (i.e. a SmartCard 

number). 
5 Subscriber Management 

System (SMS) A system managing data relating to subscribers. 

U ser A user is related to an e-mail account. There may be multiple 

users for a single subscriber. 

10 The term "receiver/decoder" or "decoder" used herein may connote a receiver for 
receiving either encoded or non-encoded signals, for example, television and/or radio 
M signals, which may be broadcast or transmitted by some other means. The term may 

also connote a decoder for decoding received signals. Embodiments of such 
3 receiver/decoders may include a decoder integral with the receiver for decoding the 

15 received signals, for example, in a "set-top box", such a decoder functioning in 
i combination with a physically separate receiver, or such a decoder including 

additional functions, such as a web browser or integrated with other devices such as 
0 a video recorder or a television. 

s 

20 It will be understood that the present invention has been described above purely by 
way of example, and modifications of detail can be made within the scope of the 
invention. 

Each feature disclosed in the description, and (where appropriate) the claims and 
25 drawings may be provided independently or in any appropriate combination. 



Reference numerals appearing in the claims are by way of illustration only and shall 
have no limiting effect on the scope of the claims. 
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CLAIMS 

1 . A method of authenticating communication between a receiver/decoder and a 
remote server for providing access to a network, the method comprising using an 

5 identifier of the receiver/decoder to authenticate the communication, the identifier 
being based on an identifier for access to broadcast services. 

2. A method according to Claim 1, wherein the identifier is stored on a 
removable component of the receiver/decoder. 

10 

3. A method according to Claim 1 or Claim 2 wherein the identifier is 
independent of a network login identifier for the receiver/decoder. 

4. A method according to any preceding claim, wherein the identifier is based 
15 on a number unique to a smartcard for use with the receiver/decoder. 

5 . A method according to any preceding claim, wherein the remote server is for 
accessing the internet. 

20 6. A method according to any of Claims 1 to 4, wherein the remote server is an 
internet account management system. 

7. A method according to Claim 6, wherein an internet account for a user is 
established by the internet account management system using the identifier of the 

25 receiver/decoder. 

8 . A method according to Claim 7 , wherein the identifier of the receiver/ decoder 
is compared by the internet account management system with a stored list of 
identifiers of receiver/decoders which may establish internet accounts. 

30 

9. A method according to Claim 7 or Claim 8, wherein the remote server 
comprises means for sending data to an internet service provider and wherein said 
method comprises the steps of providing details of the internet account to the internet 
service provider to establish a bi-directional data pathway between the 
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receiver/decoder and the internet service provider. 

10. A method according to any preceding claim, wherein said identifier is 
accompanied by data identifying a data pathway to be used for communication 

5 between the receiver/decoder and the remote server. 

11. A method according to any preceding claim, wherein the remote server 
provides the receiver/decoder with access to a network having network protocols, and 
data output from the receiver/decoder is converted into data compliant with the 

10 network protocols at a location remote from the receiver/decoder. 

12. A method according to Claim 11, wherein the data is converted into said data 
compliant with the network protocols by a gateway intermediate the receiver/ decoder 
and the remote server. 

15 

13. A method according to Claim 12, wherein the network comprises a plurality 
of remote devices, said converted data being communicated by the gateway to one of 
said remote devices as specified in said data thereby establishing a communication 
channel between the receiver/decoder and the specified remote device. 

20 

14. A method of communicating data from a non-internet protocol enabled user 
terminal to one of a plurality of internet protocol enabled remote devices, the method 
comprising the steps of: 

communicating data using said non-internet protocol from said user terminal 
25 to said gateway, said data including a message and specifying a destination for said 
message from said plurality of remote devices; and 

converting at said gateway said data into data using said internet protocol; and 
communicating said data using said internet protocol from said gateway to the 
specified destination remote device, thereby establishing a communication channel 
30 between the user terminal and the specified remote device. 



15. A method according to Claim 14, wherein the user terminal is a 
receiver/decoder . 
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16. A method according to Claim 13 or Claim 15, wherein a message instructing 
termination of the communication channel is communicated from the receiver/decoder 
to the gateway using the non-internet protocol, the gateway in turn communicating 
a termination command to the specified remote device using the internet protocol. 

5 

17. A method according to any of Claims 12, 13, 15 and 16, wherein the 
identification of the receiver/decoder is authenticated by the gateway before the 
communication channel is established. 

10 18. Apparatus for authenticating communication between a receiver/decoder and 
a remote server for providing access to a network, the apparatus comprising means 
for using an identifier of the receiver/decoder to authenticate the communication, the 
fi identifier being based on an identifier for access to broadcast services. 

£3 

M 

'q 15 ig Apparatus according to Claim 18, wherein said identifier is accompanied by 
data identifying a data pathway to be used for communication between the 
receiver/decoder and the remote server. 



U 20. Apparatus according to Claim 18 or Claim 19, wherein the remote server 

? jj 20 provides the receiver/decoder with access to a network having network protocols, said 
apparatus comprising means for converting data output from the receiver/decoder into 
data compliant with the network protocols. 

21. Apparatus according to any of Claims 18 to 20, in the form of a gateway 
25 intermediate the receiver/decoder and the remote server. 

22. Apparatus according to Claim 21, wherein the network comprises a plurality 
of remote devices, said gateway being adapted to communicate the converted data to 
one of said remote devices as specified in said data thereby establishing a 

30 communication channel between the receiver/decoder and the specified remote device. 



23. A gateway for communicating data received from a non-internet protocol 
enabled user terminal to one of a plurality of internet protocol enabled remote 
devices, the gateway comprising: 
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means for receiving data communicated using said non-internet protocol from 
said user terminal, said data including a message and specifying a destination for said 
message from said plurality of remote devices; and 

means for converting the received data into data using said internet protocol; 

5 and 

means for communicating said data using said internet protocol to the specified 
destination remote device, thereby establishing a communication channel between the 
user terminal and the specified remote device. 

10 24. A gateway according to Claim 23, comprising a plurality of input/output ports 
each for connection to a respective remote device. 

25. A gateway according to Claim 23 or 24, comprising: 

means for identifying a message from the user terminal instructing termination 
15 of the communication channel; and 

means for passing a termination command to the specified remote device. 

26. A method of, or apparatus for, authenticating communication between a 
receiver/decoder and a remote server substantially as herein described. 

20 

27. A method of, or apparatus for, communicating data from a non-internet 
protocol enabled user terminal to one of a plurality of internet protocol enabled 
remote devices substantially as herein described. 

25 28. A gateway substantially as herein described. 
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Je crois etre le premier inventeur original et unique (si un seul 
nom est mentionne ci-dessous), ou 1'un des premiers 
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Je declare par le present acte avoir passe en revue et compris le 
contenu de la description ci-dessus, revendications comprises, 
telles que modifiees par toute modification dont il aura ete fait 
reference ci-dessus. 



as United States Application Number or PCT 
International Application Number PCT/lBOO/00968 

and was amended on 

(if applicable). 



I hereby state that I have reviewed and understand the contents 
of the above identified specification, including the claims, as 
amended by any amendment referred to above. 



Je reconnais devoir divulguer toute information pertinente a la 
brevetabilite, comme defini dans le Titre 37, § 1.56 du Code 
federal des reglementations. 



I acknowledge the duty to disclose information which is 
material to patentability as defined in Title 37, Code of 
Federal Regulations, § 1.56. 



[Page 1 of 3] 



EVD4^24474£US 



,, -.- • PTO/SB/105(2-98) 

Approved for use through 9/30/98. ,OMB 0651 -0032 
o j Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE 

Under the Paperwork Redu ction Act of 1 995, no persons are required to respond to a collection of information unless it displays a valid OMB control number 



French Language Declaration 

Je revendique par le present acte avoir la priorite etrangere, en vertu 
du Titre 35, § 119(a)-(d) ou § 365(b) du Code des Etats-Unis, sur 
toute demande etrangere de brevet ou certificat d'inventeur ou, en 
vertu du Titre 35, § 365(a) du meme Code, sur toute demande 
internationale PCT designant au moins un pays autre que les 
Etats-Unis et figurant ci-dessous et, en cochant la case, j'ai aussi 
indique ci-dessous toute demande etrangere de brevet, tout certificat 
d'inventeur ou toute demande internationale PCT ayant une date de 
depot precedant celle de la demande a propos de laquelle une priorite 
est revendiquee. 

Prior foreign application(s) 
Demande(s) de brevet anteneure(s) 

99401680.6 



I hereby claim foreign priority under Title 35, United States Code, 
§ ] 19( a )-(d) or § 365(b) of any foreign application(s) for patent or 
inventor's certificate, or § 365(a) of any PCT International 
application which designated at least one country other than the 
United States, listed below, and have also identified below, by 
checking the box, any foreign application for patent or inventor's 
certificate, or PCT International application having a filing date 
before that of the application on which priority is claimed. 



Priority Not Claimed 
Droit de priorite revendique 



Je revendique par le present acte tout benefice, en vertu du Titre 35, 
^§11 9(e) du Code des Etats-Unis, de toute demande de brevet 
^provisoire effectuee aux Etats-Unis et figurant ci-dessous. 

3 



^(Application No.) 
p(N°de demande) 
ft 



(Number) 
(Numero) 



Europe 



(Number) 
(Numero) 



(Country) 
(Pays) 



Europe 



(Country) 
(Pays) 



5 July, 1999 □ 

(Day/Month/Year Filed) 
(Jour/Mois/Annee de depot) 

23 July, 1999 □ 
(Day/Month/Year Filed) 
(Jour/Mois/Annee de depot) 

I hereby claim the benefit under Title 35, United States Code, 
§1 19(e) of any United States provisional application(s) listed below. 



(Filing Date) 
(Date de depot) 



Application No.) (Filing Date) 

" " °de demande) (Date de depot) 

j^Fe revendique par le present acte tout benefice, en vertu du Titre 35, 
c 1 20 du Code des Etats-Unis, de toute demande de brevet effectuee 
Daux Etats-Unis, ou en vertu du Titre 35, § 365(c) du meme Code, de 
?4oute demande internationale PCT designant les Etats-Unis et 
pfigurant ci-dessous et, dans la mesure ou l'objet de chacune des 
*jevendications de cette demande de brevet n'est pas divulgue dans la 
Jpemande anterieure americaine ou internationale PCT, en vertu des 
dispositions du premier paragraphe du Titre 35, § 1 12 du Code des 
Etats-Unis, je reconnais devoir divulguer toute information pertinente 
a la brevetabilite, comme defini dans le Titre 37, § 1.56 du Code 
federal des regimentations, dont j'ai pu disposer entre la date de 
depot de la demande anterieure et la date de depot de la demande 
nationale ou internationale PCT de la presente demande: 



PCT/I BOO/00968 



(Application No.) 
(N°de demande) 



3 July, 2000 



(Filing Date) 
(Data de dep6t) 



I hereby claim the benefit under Title 35, United States Code, 
§120 of any United States applications), or § 365(c) of any 
PCT International application designating the United States, 
listed below and, insofar as the subject matter of each of the 
claims of this application is not disclosed in the prior United 
States or PCT International application in the manner provided 
by the first paragraph of Title 35, United States Code, § 1 12, 1 . 
acknowledge the duty to disclose information which is 
material to patentability as defined in Title 37, Code of 
Federal Regulations, § 1.56 which became available between 
the filing date of the prior application and the national or 
PCT International filing date of this application. 



Pending 



(Status) (patented, pending, abandoned) 
(Stato) (brevete, en cours d'examen, abandonne) 



(Application No.) (Filing Date) 

(N°de demande) (Data de depot) 

Je declare par le present acte que toute declaration ci-incluse est, a 
ma connaissance, veridique et que toute declaration formulee a partir 
de renseignements ou de suppositions est tenue pour veridique; et de 
plus, que toutes ces declarations ont ete formulees en sachant que 
toute fausse declaration volontaire ou son equivalent est passible 
d'une amende ou d'une incarceration, ou des deux, en vertu de la 
Section 1001 du Titre 18 du Code des Etats-Unis, et que de telles 
declarations volontairement fausses risquent de compromettre la 
validite de la demande de brevet ou du brevet delivre a partir de 
celle-ci. 



(Status) (patented, pending, abandoned) 
(Stato) (brevete, en cours d'examen, abandonne) 

I hereby declare that all statements made herein of my own 
knowledge are true and that all statements made on information and 
belief are believed to be true; and further that these statements were 
made with the knowledge that willful false statements and the like so 
made are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any 
patent issued thereon. 



[Page 2 of 3] 



PTO/SB/105(2-98) 
Approved for use through 9/30/98 OMB 0651-0032 
Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE 
Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid OMB control number 



French Language Declaration 

POUVOIRS: En tant que l'inventeur cite, je designe par la 
presente l'(les) avocat(s) et/ou agent(s) suivant(s) pour qu'ils 
poursuive(nt) la procedure de cette demande de brevet et traite(nt) 
toute affaire s'y rapportant avec 1'Office des brevets et des 
marques: (mentionner le nom et le nume'ro d'enregistrement). 
Adresser toute correspondance a: 



POWER OF ATTORNEY: As a named inventor, I hereby 
appoint the following attorney(s) and/oragent(s) to prosecute this 
application and transact all business in the Patent and Trademark 
Office connected therewith: (list name and registration 
number). 

Send Correspondence to: 
BQSENIUAJ. & OSHA LLP. 
700 Loui siana. Sgj3g323£ 



Adresser tout appel telephonique a: (nom et numero de telephone) Direct Telephone Calls to: (name and telephone number) 

Jonathan P. Osha 713-228-8600 



: =i$om complet de l'unique ou premier inventeur 

Q 


Full name of sole or first inventor 
Gilles LEBOUILL 


. Signature de l'inventeur Date 


Inventor's si g natai a£5kw^i^" — " — Date 


domicile 

« 


Residence \J i 
34, Place Raoul Dautry, F-75516 Paris, Cedex 15, France_£p/ 


sNationalite 

a 


Citizenship 
France 


2|dresse postale 

(3 

rti " ^ * 


Post Office Address 

34, Place Raoul Dautry, F-75516 Paris, Cedex 15, France 

- - - - **? 


Nom complet du second co-inventeur, le cas echeant 


Full name of second joint inventor, if any 


Signature du second inventeur Date 


Second Inventor's signature Date 


Domicile 


Residence 


Nationality 


Citizenship 


Adresse postale 


Post Office Address 



(Fournir les memes renseignements et la signature de tout (Supply similar information and signature for third and 
co-inventeur supplementaire.) subsequent joint inventors.) 



[Page 3 of 3] 



